Send v1 to v1 receivers if v2 unsupported #335
Conversation
|
I've discovered that this strategy of making a request won't work to make v1 requests from v2 in nearly every case because v2 requests will fail to build because they won't parse a public key from the payjoin endpoint. Therefore, matching should be done on the error type in extraction rather than for a response containing a "version unsupported" error that will never be received. |
Rename it from rs_pubkey_from_dir_endpoint. Return error::ParseSubdirectoryError, that covers all variants.
DanGould
force-pushed
the
v2-to-v1
branch
3 times, most recently
from
5beb7be to
efae797
Compare
|
trading extract_v1 and extract_v2 for a combined |
The subsequent extract_v2 method may fall back to a v1 request depending on the Url it is given, requiring a different content-type from a v2 request.
If no V2 subdirectory public key is available, try V1.
Fix #144
This lets v2 feature enabled senders attempt a v1 send if v2 request session public keys are not available.
It does this entirely within the send state machine and requires minimal changes upstream (just setting the
content-typeheader fromRequestinstead of manually.extract_v2return the fallback if no v2 pubkey is availableIt uncovered some of the issues with the feature gated error variants in the send module, which probably could be separated. It also uncovered that the integration tests do not use an actual HTTP server for V1 test cases, which I think is OK but I want to raise as a consideration.